Hello! Thanks a lot for your effort!

I'll definitely give it a go, but just in case I hit problems, could you also post some pictures to peak our interest?

It's a bit unfortunate that we're losing the progress bar of the loader. In the bigger files, this will look as if the program is stuck.
I'm a bit torn: On one hand it results on unresponsive UI, on the other hand we get so many nice features.

New Parameters, Message Timeline, and Message Log Series:

I agree, the progress bar is really annoying. I'm confident someone smarter than me could figure out what's going on. (I'm still suspicious it's an issue with adding the plugin to the precompiled .dmg rather than building it myself, but I haven't tested it. It seems any time I tried to create any dialog/window it crashed. Would be good to have someone recreate and confirm.
In my tests with a fairly large log, it didn't make the UI unresponsive long enough for me to worry about it. But I'm sure there's always a bigger log out there, and less capable machines that would make it a bigger problem.

As I mentioned, I got this to a pretty decent point for my needs, I actually envision this PR as a 85% solution, where someone with more experience could polish it up and get it across the finish line better than I could.

These are very cool! You should now be able to search for a parameter value right on the messages list!

The one thing that definitely needs addressing is appending the servo function on the RCO channels. This will always be breaking saved layouts, so it has to be placed behind a compiler ifdef, much like we do for the units.
It would be super if you could do that, but if not, I'll do it when I get some time.

Ah that's a really good point. I didn't think of saved layouts. I initially added them as tooltips (which would make it work), but I found it really nice to have the function name included on the plot in the legend.

In fact we could potentially put the units in the tooltip as well so we don't have to worry about the units vs non-units stuff.

I wonder if that is a way to just make the layouts a little less strict somehow for both of these cases.

I kind of like how the units print on the legend. It makes any screencaptured diagrams clearer to read.

But I don't see why we wouldn't want the units on the tooltips in either case!

Hi @trexgerratt ,

I'm having serious difficulties compiling the plugin. Neither Github CI nor Docker manage to do it, and I can't seem to navigate cmake in my bare machine.

How did you compile it?

Give me a little bit to get my machine out and going. What errors are you seeing?

I have to hit the bed now, so we'll continue as time allows.

For the CI job, you can take a look in this PR. Open the build step and read through the logs. I'm not 100% certain it would finish in this case, so I won't sweat too much about it.

But the Docker method also fails with

 > [build-stage 10/10] RUN rm -R *     && cmake -Dplotjuggler_DIR="/plotjuggler_ws/install/lib/cmake/plotjuggler" -DADD_UNITS=ON ..     && make     && make install     && mkdir /artifacts     && cp libDataAPBin.so /artifacts:    
0.226 -- The C compiler identification is GNU 11.4.0                                                                                                                                                                                 
0.278 -- The CXX compiler identification is GNU 11.4.0                                                                                                                                                                               
0.286 -- Detecting C compiler ABI info                                                                                                                                                                                               
0.348 -- Detecting C compiler ABI info - done                                                                                                                                                                                        
0.355 -- Check for working C compiler: /usr/bin/cc - skipped
0.355 -- Detecting C compile features
0.356 -- Detecting C compile features - done
0.358 -- Detecting CXX compiler ABI info
0.434 -- Detecting CXX compiler ABI info - done
0.441 -- Check for working CXX compiler: /usr/bin/c++ - skipped
0.441 -- Detecting CXX compile features
0.442 -- Detecting CXX compile features - done
0.455 -- COMPILING STANDALONE
0.456 CMake Error at CMakeLists.txt:51 (find_package):
0.456   Found package configuration file:
0.456 
0.456     /plotjuggler_ws/install/lib/cmake/plotjuggler/plotjugglerConfig.cmake
0.456 
0.456   but it set plotjuggler_FOUND to FALSE so package "plotjuggler" is
0.456   considered to be NOT FOUND.  Reason given by package:
0.456 
0.456   The following imported targets are referenced, but are missing: fmt::fmt
0.456 
0.456 
0.456 
0.457 -- Configuring incomplete, errors occurred!
0.457 See also "/apbin_plugin/build/CMakeFiles/CMakeOutput.log".
------
Dockerfile:34
--------------------
  33 |     # Ensure a fresh build folder
  34 | >>> RUN rm -R * \
  35 | >>>     && cmake -Dplotjuggler_DIR="/plotjuggler_ws/install/lib/cmake/plotjuggler" -DADD_UNITS=${ADD_UNITS} .. \
  36 | >>>     && make \
  37 | >>>     && make install \
  38 | >>>     && mkdir /artifacts \
  39 | >>>     && cp libDataAPBin.so /artifacts
  40 |     
--------------------
ERROR: failed to solve: process "/bin/sh -c rm -R *     && cmake -Dplotjuggler_DIR=\"/plotjuggler_ws/install/lib/cmake/plotjuggler\" -DADD_UNITS=${ADD_UNITS} ..     && make     && make install     && mkdir /artifacts     && cp libDataAPBin.so /artifacts" did not complete successfully: exit code: 1

My local build is probably failing because of linking problems and finding the libraries of PlotJuggler at link time. I don't have a concise piece of evidence to show.

yeah that CI job has errors I haven't run into.

I did run into all sorts of Plotjuggler dependency/linking issues. I think the main one is needing to add plotjuggler's install/lib directory to LIBRARY_PATH to get make to work:
export LIBRARY_PATH="$LIBRARY_PATH:~/plotjuggler_ws/install/lib"

For my own sanity, I started from scratch and ran the following:

clone and build plotjuggler
git clone https://github.com/facontidavide/PlotJuggler.git ~/plotjuggler_ws/src/PlotJuggler
cmake -S src/PlotJuggler -B build/PlotJuggler -DCMAKE_INSTALL_PREFIX=install -DCMAKE_POLICY_VERSION_MINIMUM=3.5
cmake --build build/PlotJuggler --config RelWithDebInfo --target install

clone and build plugin branch
https://github.com/trexgerratt/plotjuggler-apbin-plugins.git
cd plotjuggler-apbin-plugins
mkdir build; cd build
export LIBRARY_PATH="$LIBRARY_PATH:~/plotjuggler_ws/install/lib"
cmake -DCMAKE_PREFIX_PATH="/opt/homebrew/opt/qt@5;~/plotjuggler_ws/install/lib/cmake/plotjuggler" -DCMAKE_LIBRARY_PATH="~/plotjuggler_ws/install/lib;~/plotjuggler_ws/build/PlotJuggler" ..
make

The weird thing in this run through is I had to export LIBRARY_PATH with an absolute path ("~" didn't work) for some reason. I made a test directory for this run but I've still never had trouble using a ~ in an environment variable before. Weird.

I'm building natively on Mac M3.
Let me know if any of that helps or what else I can send your way.

I managed to compile the plugin, looks great! Thank you for your help getting through dependency hell.

Before we merge this PR, we need to address the following points:

1. Fix the CI so that we can compile the Windows version of the plugin.
2. Gate the RCOU functions behind an ifdef.
3. Fix the Docker build. I rely on that to have reproducible builds.
4. Potentially update the README section so that I don't forget how to compile locally in the future.
5. Find out why and fix parameters whose names and values are broken:

6. (optional) Add the units in the tooltips.

I'll try to tackle these when I get time, please be patient. Naturally, you're more than welcome to pitch in!

We should also add:

• getting the progress bar added back in.

As I mentioned, I'm using the pre built PlotJuggler .dmg, I haven't tried running the plug-in with the locally built version. I'm curious if there's any difference there. At the very least, I want to clean up that commit and separate out the progress bar so it doesn't get lost in the midst of the other changes.

I've got a lot going on right now, so I'll be slow on any of these points as well. No worries and no rush on the PR from my side either.

I wouldn't want to have to provide a custom PlotJuggler build along with the plugin. It doesn't sound like a good idea for some reason. So getting the most out of the prebuilt PJ is good enough for me.

Sorry, that's not what I mean. I agree, having a custom build of PlotJuggler is not acceptable to me either.

I just did a quick test and brought back all the progress dialog stuff. The interesting thing is the dialog works as expected* if you put the the .dylib in your local PlotJuggler build directory (i.e. ~/plotjuggler_ws/build/PlotJuggler/bin) and run your locally built plotjuggler.

However, if you download and install the .dmg version of PlotJuggler (https://github.com/facontidavide/PlotJuggler/releases/download/3.15.0/PlotJuggler-3.15.0-macOS-arm64.dmg) instead of building it on your machine and then copy that same .dylib to /Applications/PlotJuggler.app/Contents/MacOS/, the progressbar dialog window will crash plotjuggler with the following error:

QWidget: Must construct a QApplication before a QWidget
Stack trace (most recent call last):
#5    Object "QtCore", at 0x1366143df, in QMessageLogger::fatal(char const*, ...) const + 67
#4    Object "libsystem_c.dylib", at 0x19ec5684f, in abort + 123
#3    Object "libsystem_pthread.dylib", at 0x19ed51887, in pthread_kill + 295
#2    Object "libsystem_platform.dylib", at 0x19ed5b743, in _sigtramp + 55
#1    Object "plotjuggler", at 0x10446b38f, in backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 19
#0    Object "plotjuggler", at 0x10446b3df, in backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 99
zsh: abort      /Applications/PlotJuggler.app/Contents/MacOS/plotjuggler

I don't know enough about debugging QT apps, but the fact that it works fine on a local build tells me the way its packaged into a .dmg might be the issue. I know Davide is a busy guy, but I wonder if he would have any insights as it seems it might not be a bug with the ardupilot plugin code.

*well, almost. the only minor thing I'm seeing the actual blue part of the progressbar itself isn't updating, but you still get a dialog that pops up and shows the loading percentage. This is sufficient to show that PlotJuggler is loading and hasn't unexpectedly hung. This is a pass in my eyes.

I know Davide is a busy guy, but I wonder if he would have any insights as it seems it might not be a bug with the ardupilot plugin code.

I think we'll have to "bribe" him with a prize money to get him to work on that. In the recent years I think he only responds to payed requests. Which is understandable, he has a few very popular pieces of software that he maintains alone.

Oh well... we'll do our best.

@trexgerratt did you actually run sudo make install in the end? Or you manually pasted the plugin into a folder that PJ scans?
In my system it installs the plugin at /usr/local/bin/ which I think noone looks at, thus it's superfluous.